Size Change: +325 B (0%)

Total Size: 1.86 MB

_{compressed-size-action}

This is very cool to see, thanks for putting it together! Seeing the template will be helpful in many contexts, and crucial in situations like editing the Posts page.

I do think it's important that the template is only visible and not directly editable though. Otherwise we're blurring the lines between the post editor and the template editor too much. It's vital that folks understand which they are editing so that they are able to interpret whether their changes will have knock-on effects or not.

The inverse is true as well – when editing a template any visible content should not be directly editable. If you have a moment, please check out #31461 where I (crudely) explored a solution to this inverse. It may be necessary to get that interaction right as a prerequisite?

Another thing we'll probably need is a toggling affordance. IE it should be possible to edit the post with or without the template visible. See #27847.

I acknowledge this goes way beyond this PR, but is still relevant – do we need to consider how block insertion works for the Posts page? Since that page technically doesn't have any "content" and only renders a template, I don't know if it should be possible to insert blocks while editing that page?

do we need to consider how block insertion works for the Posts page? Since that page technically doesn't have any "content" and only renders a template, I don't know if it should be possible to insert blocks while editing that page?

The Posts page isnt an actual page post that can be opened in the page editor though, right? Just a template that will include posts through a query? In that case it would really only be available to edit in template editing, and block insertion should work as normal as we can and should be able to add blocks to a template itself.

On the technical side yes that is true. It's what makes this problem so tricky!

1. The Posts page is presented to the user as a page, and so loaded with all the expectations that go along with page editing.
2. The user needs access to some page editing functionality in order to change things like the title, the publish status, the permalink, or to create a new template.
3. When editing the template (in most cases this will be index) the user needs to understand that their changes can affect more than just the Posts page.

Considering that users edit this page via the "Pages" menu, coupled with point 3 from above, it seems important to open it in the Post Editor initially. This provides access to the editing capabilities outlined above. But it also surfaces the question from before.... since the "Posts page" isn't technically a page, how do we communicate that users aren't able to add blocks to it in the same way they do with other pages?

Iirc, when you edit the Posts page in the classic editor the content input is hidden and replaced with a notice. We could potentially do something similar here. That might serve as a stop-gap until we can implement a richer experience like the one in this PR.

Yeah, definitely tricky.

The Posts page is presented to the user as a page
Considering that users edit this page via the "Pages" menu

Is it currently? Or is that what we are proposing?

I think adding the 'posts page' under pages as if it were a regular page post type starts to blur the lines and confuse things a bit. Perhaps what might make sense instead is a link to something like "edit homepage template" from there in that case.

Generally the posts list has nothing but "post" post types, and the page list "page" post types. If we are going to add something to one of those lists that doesn't really correspond to those post types, we should have some form of an asterisk to convey that. Otherwise we conflate concepts of pages and templates, and blur expectations of users. We run into user confusions such as "why did this page change completely on theme switch, while all my other pages in this list stayed as they were?".

Having a link to edit that template from there could make sense, but branding it as a page entirely seems problematic.